home *** CD-ROM | disk | FTP | other *** search
/ Light ROM 4 / Light ROM 4 - Disc 1.iso / text / maillist / 1996 / 041596.doc / 000343_dwarner@webcom.com _Wed Apr 17 19:03:46 1996.msg < prev    next >
Internet Message Format  |  1996-04-25  |  2KB
  1. Received: from e55.webcom.com (e55.webcom.com [206.2.192.66]) by keeper.albany.net (8.7.5/8.7.5-MZ) with ESMTP id TAA05638 for <DWARNER@ALBANY.NET>; Wed, 17 Apr 1996 19:03:44 -0400 (EDT)
  2. Received: from localhost by e55.webcom.com with SMTP
  3.     (1.37.109.15/16.2) id AA226471830; Wed, 17 Apr 1996 15:57:10 -0700
  4. Date: Wed, 17 Apr 1996 15:57:10 -0700
  5. Errors-To: dwarner@ALBANY.NET
  6. Message-Id: <199604172236.PAA01600@dfw-ix5.ix.netcom.com>
  7. Errors-To: dwarner@ALBANY.NET
  8. Reply-To: lightwave@garcia.com
  9. Originator: lightwave@garcia.com
  10. Sender: lightwave@garcia.com
  11. Precedence: bulk
  12. From: achan@ix.netcom.com (Alan Chan )
  13. To: Multiple recipients of list <lightwave@garcia.com>
  14. Subject: Re: LW's FP precission - I AM ASHAMED
  15. X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
  16. Status: RO
  17. X-Status: 
  18.  
  19. You wrote: 
  20. >
  21. >Ernie,
  22. >
  23. >I am ashamed to say that you are absolutely right.  Ignore my previous
  24. >posts.  I was NOT scaling the sphere, that's why it was working.  I 
  25. guess
  26. >I need to get some sleep, for being so silly.  I had not realized it 
  27. was
  28. >a ratio problem (difference between micro/macro proportion), as you 
  29. had
  30. >clearly explained in your original post.  I assumed it only happened 
  31. on
  32. >macro proportions.  How silly of me: any scene with that goes over the
  33. >ratio will have problems.
  34. >It makes PERFECT sense, now.
  35. >I take the problem is LW's floating point precission, and
  36. >working with more precission should solve the problem.
  37. >Is there a way to easily work with higher precision numbers from a
  38. >programming stand-point (ie. make LW work with higher precission
  39. >by developing your own floating point routine -not being constrained 
  40. to
  41. >what the compiler's highest precission fp number is)?
  42.  
  43. The tradeoff would be longer computational times, as I understand it..
  44.  
  45. AC